by 



Life isn't easy for the authors of commer- 
cial DOS extenders these days. Their 

products must be capable of running on 
a completely standalone basis, taking full 
control of the 286, 386, and 486 proces- 
sors in protected mode, and maintaining 
all the special CPU control registers, 
descriptor tables, and page tables. And 
their brainchildren must also be able to 
coexist harmoniously with memory 
managers or device drivers that imple- 
ment any of the existing protocols or 
standards for extended memory 
allocation — be it top-down (INT 15h), 
bottom-up (VDISK), XMS (HIMEM.SYS), 
VCPI (QEMM-386 or 386MAX), or DPMI 
{Microsoft Windows 3.0). Developers of 
DOS extenders must also be masters of 
the various PC hardware architectures, 
vith all their peculiarities and ramifica- 
dons for mode switching, toggling of the 
A20 address line, and the like. This cer- 
tainly isn't a job description I'd envy, 
even if it does cany its own unique rewards 
(the staff of Phar Lap Software has been 
growing, I suspect, as quickly as the 
Microsoft OS/2 development staff has been 
shrinking). 

But DOS extenders are a technologi- 
cally fascinating topic, and fortunately 
events have conspired to place a low-cost 
test-bed for DOS extender experimenta- 
tion at our disposal. I refer, of course, to 
the implementation of the DOS Protected 
Mode Interface (DPMI) in Windows 3.0. 
First, let's review how "real" DOS ex- 
tenders work, and then we'll implement a 
simple little DPMI-based DOS extender 
of our own. 

THE TWO FACES OF A DOS EXTENDER 

A typical DOS extender that you might 
buy from Phar Lap or Rational Systems 

can be thought of as having two main 
sections: an initialization component and 
an interrupt handler component. The ini- 
tiali2ation portion of a DOS extender gains 
mtrol of the machine when the DOS 
extender is loaded by DOS in real mode 
as a result of a user command or an INT 
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DOS Protected Mode 
Interface gives us a low- 
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21h, function 4Bh (EXEC) function call 

by another program. In most cases, the 
DOS extender and the protected-mode 
application (such as Mathematica, Auto- 
CAD, or Lotus 1-2-3, Release 3.0) are 
bound together in the same .EXE file. 
However, the only part of the file visible 
to DOS is the DOS extender, because it's 
the only part described by the .EXE file 
header and relocation table. 

The initialization routine has a lot of 
work to do before the protected-mode 
application can start mnning. It must probe 
the environment and determine whether 
it's running on the bare hardware (aside 
from DOS) or in the presence of one of 
the several species of memory managers. 
It must allocate some extended memory 
and load the application's code and data, 
performing any necessary relocations and 
fixups. It must allocate additional con- 
ventional memory (memory below 640K) 
for communication with MS-DOS and 
the ROM BIOS. It must build the neces- 
sary global and local descriptor tables to 
support protected-mode addressing, which 



includes mapping some descriptors onto 
"magic" memory areas like the PSP, the 
environment block, the video refresh bulTer, 
and the ROM BIOS data area, for the 
convenience of the application. It must 
switch the CPU from real mode into protected 
mode. And it must take full command of 
the CPU's interrupt subsystem by build- 
ing an interrupt descriptor table, repro- 
gramming the 8259 interrupt controllers, 
and installing handlers for every type of 
interrupt that might occur in protected 
mode. 

From the DOS extender's point of view, 
there are three types of interrupts to worry 
about. TTie first group consists of the CPU 
faults or exceptions, usually caused by a 
program error but sometimes by a hard- 
ware error (for example, a noimiaskable 
intermpt due to a RAM parity error) or an 
unexpected result on the numeric coproces- 
sor. The second group consists of the 
extemal hardware interrupts — signals that 
a peripheral device has received data, is 
ready to accept more data, or has encoun- 
tered some other condition that needs 
attention. The third group are the soft- 
ware interrupts, which occur when an 
application program executes an INT 
instruction. Control over software inter- 
rupts is a particularly crucial aspect of 
DOS extender initialization, because it 
allows the DOS extender to function 
transparently by intercepting the applica- 
tion's requests for ROM BIOS and MS- 
DOS services. 

The exact order in which the DOS 
extender will perform these initializatiQn: 
chores depends in part on the philosophy 
of the implementer and in part on the 
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environment in which the DOS extender 
will run. For example, XMS and VCPI 
memory managers require that the DOS 
extender make its memory allocation calls 
in real mode, while requests to a DPMI 
host for memor)' must be made in pro- 
tected mode. Similaiiy, techniques for mode 
switching differ with the PC architecture 
(PC/AT, PS/2, and so forth) and with the 
presence or absence of XMS, VCPI, and 
DPMI. The only things we can say for 
sure about the initialization sequence are 
that a minimal global descriptor table (GDT) 
must be constructed in real mode and that 
the CPU must be in protected mode be- 
fore control passes to the entry point of 
the actual application program. 

Once the application is launched, the 
DOS extender's initialization section is 
dead code; the memory it occupies can be 
reclaimed and reused. The application's 
code now becomes the center of the ac- 
tion. The remaining parts of the DOS 
extender are activated only upon the 
occurrence of one of the three kinds of 
interrupts listed earlier. In this respect. 



lllC J_/V-/0 CAlCllUCi IS lliucil lilv.1.. a iv.,ai- 

mode terminate-and-stay-resident (TSR) 
program. But the DOS extender's status 
after initialization is somewhat more slip- 
pery than that of your average TSR. 

From MS-DOS 's perspective, the DOS 
extender is the only program that's run- 



The fully initialized 
DOS extender can be 
thought of simply as i 
grab bag of interrupt 
service routines. 



ning, and it's a perfectly ordinary pro- 
gram at that: it lives in the memory that 
MS-DOS allocated for it. and it makes 
normal MS-DOS function calls. From the 
protected-mode application's point of view, 
the DOS extender is nearly invisible (in 
fact, the more invisible, the better the 
DOS extender); the application reqifests 



executing the usual software interrupts, 
and somehow the right things happen — eve 
though the interrupts are being executea 
in protected mode and the application is 
passing virtual addresses of data and buffers 
lying in extended memory. 

Looking at the DOS extender from the 
inside out (the viewpoint of its author), 
the fully initialized DOS extender can be 
thought of rather simply as a grab bag of 
interrupt service routines. 

When a CPU fault or exception oc- 
curs, the DOS extender usually has little 
recourse but to terminate the protected 
mode application, unless the application 
has explicitly registered its own handler 
for the interrupt. If the application has 
gone so far awry as to cause a stack under- 
flow or general protection (GP) fault, for 
example, it's obviously ailing and will 
only cause more trouble if it's allowed to 
continue. (Interpreters and debuggers are 
obvious exceptions.) 

External hardware intermpts are treated 
differently. If the protected-mode appli- 
cation hasn't registered a handler, the 
interrupt is "reflected" to the original 
real-mode owner of the interrupt. In other 
words, the DOS extender fields the inter- 
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title 
page 

TiMYDOSX.ASM Tiny DPMI-Based DOS Extender 
copyright <C) 1993 Zi£f Davia CtMnniunications 
PC Hagazine * Ray Duncan 



stdin 


equ 


B 






Standard input handle 


stdout 


egu 


1 






standard output handle 


stderr 


equ 


2 






standard error handle 




aqu 


0db 






ASCII carriage return 


:f 


aqu 


Bah 






ASCII line feod 


DOROOP 


group 


_DftTA 








_DATA 


segmfnt 


-■''ord publi 


c 'DM*' 








dd 


e 






tar pointer to dphi mode 












switch entry point 


i.-.tadv 


dd 


Q 






address of previous 












GP fault handler 


ir.taiv 


dd 









address of previous 












Int 2lB handler 




e 






eegment of real mode buffer 




dw 


B 






selector for real mode buffer 




db 


cr.lf ,lf 










db 


' TIKYDOSX ! 




protactiob fault 1 ' 




db 


CE.lf 












S-gpfaiag 










db 


cr.lf, 1£ 










db 


■TISYI>OSXt 


unsupported DOS functioni' 




db 


cr,lf 








abmsg len equ 


$-abinsg 








rags 


label 


word 






rssl mode register structure 












for DPMI translation ffisirvices 




label 


word 






aSH 01 or EOI 


regSDi 


dd 











regSl 


label 


word 






S4H SI or ESI 


L-ogESI 


dd 


e 








regBP 


label 


word 






aSR BP or EB? 


regEBP 


dd 


2 










dd 









iCH (reserved) 




laoel 


word 






IflR 3X CT EBX 




dd 


S 










label 


word 






14H OX or EDX 


Leg2DX 


dd 











rsgcx 


label 


word 






18H CX or ECX 


regscx 


dd 











regiUt 


label 








ICH AX or EAX 



prots: dl* 
protES dw 



offset 
□ffaat 
offset 
offset 
offsat 
offset 
of fiat 
offaec 
offeat 
offset 
offsat 
otfeat 
offset 
offset 
offset 
offset 
offset 
offset 
offset 
offset 
offset 
offset 



iffsat _7EXT 
iffseC _TEXT 

TEXT : i 
TEXT 1 3 



offset ' 
off sot " 

off BSt ' 

Offset " 
offset [ 
offset 
offset ; 
offset 
cElset ' 
offset 
offset ' 
Offset " 
offsat ' 



TEXT:£xa»flh 
>EXTtfxneih 
^TEXTtfxnaih 
"TEXTifxn83h 
'text ! f xn34h 
"TEXTiExnaSh 
■"TEXT:fxn06h 
"TEXTifxn87h 
'TBXTifxnflSh 

"text ! abort 
"TEXT! abort 
"TEXTifxnebh 
[TEXT! abort 
"TEXT;fxr.adh 
|TEXTif Jicaeh 

_TEXT'! abort 
"texti abort 
"TEXT! abort 
"texti abort 

'TEXTiSboct 
TEXT: abort 
TEXT; abort 

'text I abort 
]TEXT!fxnlbh 
"TEXTif xnlch 
>EXT! abort 
TEXT : abor t 

"text 1 abort 

>CXT:abort 
VexT: abort 
TEXT 1 abort 
TEXT: abort 
"text ; abort 
TEXT: abort 
TEXTS abort 
TEXT:abcrt 

'text : f xaiah 



offset "tEXTi flOl2cll 



; 2SB cpu Status flags 

t 23R KS 

: 24H DS 

: 26B FS 

: 23!! GS 

2ah IP (CSiiP ignoceci by 

■ 2CH CS DPMI fur.ction eSSflH) 

2er s? (ssispoa to have dpki 
3flR SS host aujaply a staaki 

save protected mode ox 
save protected mode S: 
save protected mode ES 

Int 21H dispatch table 
fxB iia Certninate 
fJtn JlB char inpat+echo 
txn 923 chsr output 
fxn 93b anx input 



in 



fxn asR prii 



itpuE 

.E O'-tput 



fxn esa input status 



fxn 19H get current drive 



1 2aH get date 
1 2BB set date 
1 ?^_.,g|rt tijna 



Figure 1 : Here's the source code for a skeleton DPMI 0.9-based DOS extender that can be linked with small-model C programs. 
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rupt, saves the CPU state, switches the 
CPU into real mode, and reissues the interrupt 
with an INT instruction. When the real- 
mode handler executes an intemipt return 
(IRET), the DOS extender recovers con- 
trol, switches the CPU back into protected 
mode, restores the CPU state, and then 
issues its own IRET so that the applica- 
tion can continue. 

Which brings us to the last category of 
interrupt that the DOS extender must dis- 
pose of: interrupts that are explicit MS- 
DOS or ROM BIOS function requests by 
the application. There are a number of 
different software interrupts that the 
DOS extender must be prepared to cope 
with: MS-DOS's INT 20h through INT 
2Fh, the ROM BIOS video driver INT 
lOh, serial port driver INT 14h, keyboard 
driver INT 16h, printer driver INT I7h, 
Microsoft Mouse driver INT 33h. and so 
oil. Each one of these interrupts provides 
a pathway to a host of different subfiine- 
tions, typically selected by a value in register 
AH. For instance, more than 80 functions 
(both documented and undocumented) are 
ifined for INT 2 1 h. As I explained in the 
last column, these functions can be di- 



■ functions that require little more than 
a mode switch before passing them down 
to MS-DOS or the ROM BIOS; 

■ fiinctions that address application buffers 
and therefore require data movement and 
address translation before they can be 
reissued to MS-DOS or the ROM BIOS; 

■ functions that must be completely re- 



In any event, the DOS 
extender's handling of 
an MS-DOS or ROM 
BIOS service request is 
easy to visualize. 



placed to make them meaningful in pro- 
tected mode; and 

■ function calls that are unique to the 

DOS extender itself and provide special 
services that have no equivalents in MS- 
DOS or the ROM BIOS. 

There is also an implicit fifth class of 
functions, which I didn't mention previ- 



i/ui>ij. uiv- iyiL}-uKJ,j luiltuoiis lllttl lliC 

DOS extender author simply chooses not 
to support because they're either too 
dangerous or not worth the hassle. The 
FCB file functions, the direct disk I/O 
functions, and some of the undocumented 
DOS functions that vary tremendously 
from one version of DOS to another are 
good examples. 

In any event, the DOS extender's handling 
of an MS-DOS or ROM BIOS service 
request is easy to visualize. An umbrella 
routine is entered first; it saves the CPU 
flags and all the general and segment 
registers for later reference. The umbrella 
routine then decodes the function request 
by using the function number in AH as an 
index into a jump table, and then passes 
control to a handler that is specific to the 
function type. Functions that pass all 
parameters in registers and don't refer- 
ence data in extended memory can fall 
through to another umbrella handler that 
performs the necessary mode switching 
and reissues the interrupt in real mode. 
Nearly all functions that pass addresses 
of buffers or pass parameters by refer- 
ence must be handled on an individual 
basis, because there's regrettably little 
symmetry of structures or register usage 
across DOS and ROM BIOS function 
calls. Of course, memory management 
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offset 
offaet 

offset 



offset 
offaat 
offsat 
Offset 
offset 
offset 
offset 

OffMC 

offset 
offset 
offaat 
offset 



offset 
offset 
offset 
offset 

offset 
offset 
offset 
offset 
offset 
offset 
offset 



_TEXT:f xn2dh 
_TEXTifxn2eh 
TEXT! abort 

_TEXT : abort 
"text t short 

1EXT:fXR331l 
"TKXT-.sbOrt 

TEXT: abort 
_TEXT:flcn36h 

_TExri abort 
_TEXT ; error 
_TEXTTfxil39h 
_TEXT; fxn3ah 
_TEXT!fxn3bh 
_T3XTifxn3ch 
"text; £xn3dh 
^TSXT: fx!;3eh 
TCXT if XT.afh 
SEXTifxiUflh 
_TEXT:fxn41h 
_TEXT:fKn42h 
_TEXT:fXIl'13h 
"TEXTiSrror 

TEXT: :Kr4t h 



TEXTterror 
^EXTierroc 

''TEXTjfxn4ch 
"text : abort 
'^TEXT: error 
"rEKT! error 
TEXT -.abort 
TEXT 1 abort 
'text ; abort 
TEXT: abort 
|TEXT.fjin5ih 
'tsxt : sbort 



_TE:XT:fxr:Sbh 

_TEXT: abort 
_TEXT; error 
_TEXT:arror 

~TEXT: abort 
"text: abort 



_TEXT:e 
TEXT: a 
"TEXTie: 



offset 
Offset 
offset 

offset 
offset 
offset 
cffset 
offset 

offset 



o£CMt lEXTiAbort 



fxi 



2FI] 



fxn 3flH got DOS versior. 
fxn 31H 
fxn 32s 

fxn 33B get/set break flag 
fxn 34a 



I 3SB 



i get drive info 



; creste directory 
: rielate dir-ectory 
'. select directory 

L close file 
I read file 
t write file 
[ delete file 



: fxn 44H 

fxn 45H 
fxn 4SH 
fxn 47B 
fxn 4aa 
fxn 49» 
fxn 4AS 
fm 4BH 
fxn flCH 
fxn 4 OH 
fxn 4EH 



redirect handle 
get BUT. directory 



fxn 56H 
Exn 57K 
fxn 58H 



get verify flag 
get/aet file date 



1 5MI create te^ file 
1 5BH create unique file 
I 5CH lock/unlock 



fxn SDH 
fxn SSH 
fxr 5FH 
fxn 69H 



fxn 6SH cownit file 



DATA 
TEXT 



offset _TEXT!abort 
offset _TEXTiobort 
offset ~TEXT:error 
offset _TEXT:atiort 

oileet _TEXT!abort 
offset TEXTiabort 



segnent syta public 'C<^E' 

assur.e cs :_TSXT,dsiDGROUP 



initialization routina for the Tiny DOS Extender. First we test for 
the presence of a DPXI host, get. the address of the mode svitch entry 
pcint, ar.d rei;uest the switch to protected aode. Then we install 
a handler for GP faults to circiunvent Che Kin 3 brain-dasaged dialog 
90X, sad allocate soke ireatory below 1 hb to ose as a baffer for 
cccffunieaLiTCi with DOS. finally we Ir.scall our own Znt 21B taaridler 
so we car. service DOS calls firom the jirotected mode spplicatioa. 

public; Initdosx 



gat address of dphi 

mode switch entry point 
bail out if no DPKI 

save far pointer to 
D?HZ entry point 



dx, offset _TExi(gpfisr 

31h 

initS 



initS 

realsol.dx 



jtiicp, allocation failed 

pass segnent cf data area 
bit 0<^e indicates IG-bit app 
switch to protected mode 



; ins-ci: c- fault handler 

; CX:DX = handler address 

; couldn't install 

; allocate 64 KS buffer in 

; conventicnal yiemory for 

; csmmunicetion with cos 

• jtunpr alloestion failed 

; save segment of block 

; save selector for block 



I gat address of pmrieoa 
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function calls must be trapped and serv- 
iced entirely within the DOS extender, 
and this can be a fair amount of work in 
itself (particularly if the DOS extender 
supports virtual memory). 

One more function that bears men- 
tioning is INT 21h, function 4Ch, which 
an application calls to terminate itself. 
When the DOS extender sees this func- 
tion request, it must deallocate its (and 
the application's) extended memory, re- 
lease the interrupt subsystem, and remove 
any other little tendrils it may have in- 
serted elsewhere. This is tricky business, 
because the DOS extender — which has 
been playing the role of a little protected- 
mode operating system that uses DOS as 
a file system slave — must quietly and 
gracefully put everything back exactly as 
it was before the DOS extender was loaded, 
leaving the system canpletely stable. Finally, 
the DOS extendfer must switch the CPU 
into real mode for the last time and itself 
call INT 21 h, function 4Ch, so that DOS 
knows to free all conventional memory, 
file handles, and other resources that were 
assigned to the DOS extender. 



A SIMPLE DPMI-BASED DOS EXTENDER 

I always find source code much more 
enlightening than windy explanations, so 
I've illustrated the foregoing discussion 
of DOS extenders with TINYDOSX.ASM 
(Figure 1), a skeleton DOS extender that 
you can use in your own programs. 
TINYDOSX relies only on the existence 



Memory management 
function calls must be 
trapped and serviced 
entirely withiin the DO^ 
extender, which can be 
a fair amount of worlc. 



of a DPMI 0.9 host, such as the one found 

in Windows 3.0: it can be linked into any 
small-model C program and will cause 
that program to execute in protected 
mode — ^provided you don't call any run- 
time library fianctions that include self- 



modifying code, use segment registers 
for scratch storage, perform segment reg- 
ister arithmetic, or in general execute an 
instruction that will result in a general 
protection fault. Although Windows 3.0 
includes a DOS extender of its own. 
TINYDOSX doesn't use it and will run 
just as well in other DPMI, Version 0.9, 
environments (at least theoretically: no 
other such environments exist for testing 
at this time). 

The initialization pctttion of TINYDOSX, 
embodied in the routine INITDOSX, is 
straightforward. To keep things simple, 
we allow the C application to get control 
first in real mode, and require it to explic- 
itly call the DOS extender, rather than the 
other way around. INITDOSX first calls 
INT 2Fh. function 1687h to find out whether 
a DPMI host is present, and if so, the 
address of the mode switch entry point. If 
a DPMI host is not found. INITDOSX 
bails out with an error message; other- 
wise, it proceeds to allocate the private 
data area required by the DPMI host and 
then requests the switch into protected 
mode. 

Once it's running in protected-mode, 
INITDOSX installs protected mode han- 
dlers for MS-DOS INT 21h and for general 
protection faults (so that Windows won 
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bL,21h 
31h 

word ptr int21v,dx 

viord ptr iDt21vt-2,< 



dx.offaet ^TEXTtdoacall 



] ownar o£ int 21B vector 

f BAVB aa far pointer 

I install our Int 21B handler 

; CXiDX - handlar address 



nitdosx endp 
Interrupt service rout: 



! from DPMI bos 


. with cs 






! r«tttrn Address in the 


gpfisr proc 


far 


push 


bp 




bp.sp 


mov 


%mrd ptr 


pop 


bp 



; raturn in protected mode 
I AX ■> to signal auccsaS 



n.e for GP faults. Entered by a far oslL 
IP, flags, CPU error coda on Btaak. 
r error message routine by changing 



; point CSiIP in stack frame to 
I GP faalt error neseage routine 
_TRXT:gpEarr 



.-.i.-^LLi ^;-_ = i -.hfe CPFIER returns to ih-- 
-Splays an error -£sss.qe and teminatee cleanly, 5Ubi 
lication bas violated syatea intaQrity" dialog box. 



dx, offset C>GROUP:9pfsiS9 ; display CP fault itessaqe 
cji,gpfr3g_len ; on atacdard output 

bx, stdout 
ah,4«fa 

2ih 

ax,4ceib ; and tennir.ate with 

2lh 



iprerr ©asp 

The DOSCALL routine is the runtime portion of the Tiny DOS Sxtender- 
It traps int 21h requeeto in protected ciodo and porfonns any nececsary 
node awitchinq, date movement, and address transXation on a 
functioB-by- function basis. Anything DOSCALL doesn't want to hsndle, 
1 it eitber fails by setting the Carry flag and returning, .or 
I it aborts the current progrein. In particular, all FCB-telated 
: functions are aborted, when a termination function is detected, 
: rhe int»er«pt bendlsro nro unhooksd and the Amotion cell ie 
i passed down to the DPHI host so that all other protected mode 
: reaourcea will be deallocated. 



dosca I 1 proe 



add 



n06h: 

f xnOah: 
f xnflbh : 

fxnSeh: 

fy.nlbh: 
f y-nloh: 
txnlah: 
f xnJbh : 
fxnlch: 
JxnJdh: 
f Kn20h: 
f xn30h; 

fxn36h; 
rxnJeh-. 
fxn42h: 
fxn45b: 
f Kn46h t 
fxn54h: 
fxR57h: 
fxnSohi 
fsn68h! 



bl,ab 
bh,bh 
bx,6fh 



dx, offset DGKOUPiabmeg 



int 


2lh 




ax,4ceih 


int 


21^1 


push 


bp 








word ptr 


pop 


bp 
ax,l 


iret 





function no. too big? 
yes, bail out 
no, brar.ch through table 
to function handler 

unsupported DOS function 
display error message 



;it to DOS 



; unsuppo:rted DOs fi;nctio.n 

; set carry flag in stack 

; frame to indicate 

; function f ailod 

; load AX = error code for 

; "invalid function number" 

; return to applicat-on 

; cormon handling for entirel' 
; regis tec-iased f unctior::: 

; function 313: char i^.put^e-^; 

: function 92H: char output 

: function fl 3H : aux i.^FUt 



r.etlon 04H: 
nction 35H: 
nction B6H: 
nction B7B: 
r.ction 08H: 
nction OBH: 
nction 0DB: 
I 0EH: 



functii 
functii 

foncti: 

functi. 
fum 



r output 
lie I/O 
raw input no echo 
char input no echo 
input status 
disk reset 
select disK 
get current dr ive 



IBHi 

ICHt get dri' 

ZAH : 



function 2t>B 
function 2EH 
function 3flH 
function 33a 
function 36B 
function 3EQ 
function 42H 
function 45H 
function 4SB 



73H: set date 
2CB: get Til-ire 

set verify flag 
get DOS version 
get/set break flag 
get driwe info 
close file 



dup handle 
redirect handle 
faact.lQn 54Si g^ verify flag 
£unction 57B: ^t/set filerteto 
function ScHt lock/unlock 
function 68H1 commit file 
restore BX 

unload general registers 
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4of 4 1 








; trar,a£eJ7 to DOS 


fxrl4Ch: pop 




I function -JeBi terminate 




call 




J load general register's t £i*gs 






; Save return code 




Irev 


J j^etum to appl ic at xon 




ax, a203h 


i restore old ap fault handler 








J ccMfunon nandl ir-g foi lunct ions 
; pass ing ASCI I Z aHdi- in DS : OX 


^v 


bl, Bdh 

cx,word ptr intfidV'-S 
dx.word ptr intBdv 




£xn39h 






; function 39Hi create diiroctoiy 




31h 










J tunction 3AH: delete directory 




ax, 2e5h 


I restore old Znt 21H handler 


f jtn3t.|-i 






; function 3BH: select directory 


mov 


bl, 21h 




f xn3oh 






) function 3CK1 create file 




cx,word ptr int21v»2 










; function 30H: open 


mov 


dx.word ptr int21v 










; fttnction 41H1 delete filo 


int 


3ah 




Exn-lSh 






J function 43H! get/set att-ibute» 


mov 


ax.aifllh 


; xreleasa real mode buffer 


fxnbah 






J function 5AHj create tamp fil© 




dx.realael 




f K 11 5 t>h 






; function SBH ; create unique file 




3ih " 






pop 




; restore BX 


pop 


ax 


; chain to DPMI rnt 21H handler 




call 

mov 


aaverege 


; unload general Eegi seers 
; ss iDI — virtual address of 


irt 


21b 


; for cleanup and termination 








; real iriodo buffer 


chaini 




; general f allthrcugh point 








; US ;si — virtual address o£ 




f (Useful during debnggingj 




eld 




pi-of-=i.-:ted mode buffer 


pop 


bx 


; sestore register BX 








; ccpy ASCIIZ sLring to 


jmp 


int21v 


; chain to prev Int 21 H owner 








; real ir.odt. butter 










al al 


; reachod r.u 1 I yi?t7 


coscal 1 ei'.Jp 








]nz 




; no , ucpy a:iot;her character 












J set iddres3 ct real m<r.d« bjffer 






data structure for a call to 








; into register data structure 


: Save general 


registers into real mode 




mcv 




J real mode roatine via DPHZ translatlo 


n services. Mote that segment 








{ trariafer to MS — bos 


; registers are 


MOT unloaded Into structure because they are not valid 




call 




; load geneiral registers i. flags 


; for real mode 


anyway . 






mov 




; restore protected mode DX, 








mov 


es.protES 


; return to application 


saveregs proe 


near 






1.x at. 














; Euncti.on 3FH : read £ i le 






; save general registers 


pop 




; unload general registers 


mow 


regsx, bx 
regcx.cx 
regDXfdx 










; set address of real mode buffer 


ir.ov 






mov 


reaDS*ax^^ 
r^eqDx' S 


; into regla-ter data structure 




regsi , si 
regDi,di 






call 


raaldoa 


; -transfer to HS— DOS 




regBP, bp 


; extra copies for non- 








J CX = actual length of data 


mov 


protDX.dx 




push 


ds' 


; ES:DZ — virtual address o 1" 


mov 


protsi, si 


i register-based functions 








J protected mode bii t ter 




prctBS , ee 






m^v 


dXrproCDX 


; DS jSI = vi r tual address of 


ret 








mov 


ds , rea Isel 












si ,bL 


; real mode bu f £ is r 


saveregs endp 








'^^^ 




j copy data £ron real mode 








re mo 




; buffer to pro tec to-.! mode touf f er 


; Load gsneraX 


reciisters from real mode 


data structure. Hote that 






ds 


; restoi-d DS = our DGROUE' 


; STsgnient regi a 


tars are not loaded because their real mode values 






; load general registers 


; would cause a 


GP fault in protected mode . 




mov 


dx, pEOtlDX 


; restote prot,ect.ed mode DX , ES 


loadrega proc 








mov 


, protES 


; return to appli-catibn 








lr«C 








r update CPU flags in 










bp, sp 


f xnJ.ih 






; function 49Ht write filtJ 




L-pu FLAGS 


; stack frame to return 




P"P 




; restore BX 


pop 




;, D<^ function status 




cal 1 




; unload general registers 

! B5:DI = virtual address of 




^y., i-p^gAX 


; XOad general registers 




xor 


di. 
















I DS:SI •> virtual addi.<i=^5 of 




dx , regDX 










; protected mod^ buffer 




si, rpgyi 










; copy data to re al mode bu £ fer 




di, reqDI 






^ep mo 


ax, ceals^g 


; sat addre^A of rea 1 mode bu £ fer 




bp , regBP 










; into register data ^tructu re 


ret 






mov 


regOX, B 












call 
aaTi 


realdos 
loadrags 


; transfer to ms-dos 

I load general registers & flags 


loedregs endp 










dx.pcoCDX 


; restore protected mode DX, ES 


; Call the DPH; 


translotion function 03a0H to simulate a real node 




mov 


es , pcoCBS 


; retucn to application 




rrupt 2'H, t r ansf err ing 


ccntrol to ms-DOS. passing 








; the values st 


ored into the real mode 


register structure -regs'. 








; function 47H: get directory 










pop 


bx 


: restore BX 


realdos prc.c 








call 




; unload genera 1 reg 1 ster s 














; set address o£ real mode bu£f er 












iregDS , ox 


; into registsr data atructure 


ax, B30eh 


; CPMX Function 0300H 




mov 


regsr, 






bl,21h 


f software interrupt 21H 




oil 


EOaldos 


; transfer to KS-DOS 




bh, 


f flags <bit must be B) 




push 


ds 


; ESiDI " virtual address cf 




CX, e 


; no ■ oC stack words to copy 




pop 




t protected in ode biifii^r 


push 


ds 


; ES ; DI " address of real 






di , pcotsi 




pop 


es 


; mode register structure 






ds , roaioel 


J DSiSI ^ virtual address cf 


dl, offset DGROOPjregs 










; real mcde buffer 


int 


31h 


f to OOS via DPMI host 




old 




; copy Ascriz a c ring from real 


pop 












; inod© buffei- to prot: nod-? buffer 










al.al 


; found oull character yet? 


realdos endp 








jnz 




; no, copy another character 








puati 




; restore DS = our dgroup 










pop 


ds 




_TEXT «Dd« 








call 


loadregs 
al, proi^sx 
es , protES 


; load genera 1 registers 

1 restore protected node SI , ES 










ir-Bt 




; return to application 








fxnash 






; function flflHi terminate 









blow our little programming blunders out 
of the water with its totally uninforma- 
tive "Application has violated system in- 
tegrity" dialog box). INITDOSX also 
allocates a 64K area of conventional memory 
that the INT 21h handler can later use to 
pass data back and forth to MS-DOS. 
Finally, INITDOSX returns control to the 
C application, which continues its execu- 
tion in protected mode. 

When the C application requests an 
MS-DOS service, the protected-mode INT 
21h handler, named DOSCALL, receives 
control. DOSCALL saves the flags and 



registers, then branches through the table 
DISPATCH to the appropriate subrou- 
tine. As you'll notice, I've stubbed out 
most of the less-common DOS functions 
to either retum an error or abort the appli- 
cation. The functions that TINYDOSX 
supports, however, are relayed to DOS 
using the DPMI translation function 
' Simulate Real Mode Interrupt." Use of 
this translation function, rather than the 
speedier DPMI "raw mode switch" func- 
tion, eliminates all sorts of messy prob- 
lems that are best left to the imagination 
and experiments of adventurous readers. 



Naturally, DOSCALL monitors for the 
fateful INT 21 h, function 4Ch, and cleans 
up after itself accordingly. 

Assuming DPMI 0.9 as our platform 
and linking TINYDOSX directly into the 
protected-mode application allows us to 
take some shortcuts that would never suffice 
in a commercial-grade DOS extender. 
First, we don't have to build our own 
loader for the protected-mode applica- 
tion; since TINYDOSX is linked into th^^- 
application, DOS loads TINYDOSX at 
the application as a single unit. Second, 
we don't have to allocate any memory 
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TINYDOSX.C 



TESTZ>osx.c — — £lluBt.r-at:eB use of 'the dfhz -based 

DOS Extender tzz9XT>osX -to dlapXay a meaaage in px-oteoted mode 

Copyirlght <C} 1990 Zl££ Davis coaimvinica'tlone 
PC Magazine * Ray Duncan 

Build with Microsoft c 6.0 SMAl-i:- model as follows ( 

HASM TXHVDOSX; 

CL TESTDOSX.C TINTiDOSX 

Execute under windows 3.0 in the DOS Box onlyl 

*/ 

•include <stdio.h> 

unsigned extern paocal XnitDosX(VOid) ; 

main< > 
{ 

unsigned saveCS, saveDS; 



_asm mov saveCS,cs 
asm mov 8aveDS,ds 



; store xreal mode CS 
; and ds for display 



printf <*>\nHello, real mode worldl \tCS— %04xh DS— %04xh'* 
savecs , saveDS ) ; 

if <lnitDo8X( ) > // attempt mode switch 

{ 

put8("\nDPMI initial! 2 at i.on feklled."); 
exit < 1 ) ; 



_asin mov aaveCS,cB 
asm mov saveDSfds 




; stoire pzrotected mode CS 
; and DS for display 



tello, protected mode world* \tcs-«04xh Ds«-%04xhVn 
saveDSj ; 

4ah ; exit directly to DOS to avoid 

; GP fault in RT£> cleanup code 



Figure 2: This is the source code for a simple protected-mode C application that can be linked 
^' h TINYDOSX.ASM, listed in Figure 1 . 



for the application or build any descrip- 
tors; we get these services "free" when 
DPMI creates code and data selectors during 
the initial switch to protected mode. Third, 
we need to support only those DOS serv- 
ices in our DOS extender that we know 
our application is actually going to use; 
we don't have the obligation to translate 
every known (and unknown) DOS func- 
tion for protected mode the way a "real" 
DOS extender does. 

Suppose we wanted to turn UNYDOSX 
into a not-so-tiny, more robust DOS 
extender — where would we start? We'd 
have to enlarge the support for INT 21h 
functions to include (at minimum) all the 
documented MS-DOS services. We'd need 
to support the immense battery of ROM 
BIOS services (most of which, luckily, 
are register-based anyway) and probably, 
in addition, the Microsoft Mouse INT 
33h and the NETBIOS interfaces. We'd 
want to add more sophisticated facilities 
for installation of interrupt handlers by 
the application. And last but not least, 
we'd be obligated to support most of the 

Terent C memory models, a somewhat 
iiiomy chore. My first impression of the 
way to do this would be to incorporate a 
loader for ' 'segmented .EXE' ' (also called 



"new .EXE") files into our DOS exten- 
der, build the appUcation with the Micro- 
soft Segmented Linker, and bind our DOS 
extender into the .EXE file as the ' 'real- 
mode stub." 

TRYING OUT TINYDOiSX 

TESTDOSX.C, a simple protected-mode 
C application that can be linked with 
TINYDOSX.ASM, is shown in Figure 2. 
To create the executable version of TEST- 
DOSX, enter the following commands: 

MASK /Mx TIMYDOSX; 

CL XESTDOSX.C TINTOOSX 

Be sure that you are using Microsoft 6.0 
and compiling for the small model. The 
resulting application, TESTDOSX.EXE, 
must be rim in one of Windows 3.0's 
DOS boxes so that it has access to DPMI 
services. 

THE IN-BOX 

Please send your questions, comments, 

and suggestions to me at any of the fol- 
lowing e-mail addresses: 
PC MagNet: 72241,52 
MCI Mail: rduncan 

BIX: rdtmcan ■ 

MARCH 12, 1991 PC MAGAZINE ESQ 



computers, PCG 
Class A, Class B, 
and You — 

or When is it 
better to get a 

B tKan an A? 

You need to know the difference 
between computers that meet the 
FCC class B radio frequency emis- 
sions standards and those that meet 

only the Class A standards. 

Computers emit radio signals in their 
operation. Because these signals 
may cause interference to radio and 
television reception, the marketing 
and the use of computers is regulat- 
ed by the Federal Communications 
Commission. Under federal rules, 
computer users are responsible for 
remedying interference, including 
interference in neighboring homes. 

Computers ceitified by the FCC as 
meeting the Class B standard are 
less likely to cause interference to 
radio and TV reception than those 
that have been verified by the man- 
Lifacturer or importer to the Class A 
standards. Only Class B certified 
computers may be advertised, sold, 
or leased for use in residences. A 
similar regulatoiy program applies in 
Canada. 

Buyers seeking computers for use in 
homes (including offices at home) 
should shop for computers and 
pei ipherals which have been Class B 
certified. These devices carry a label 
with an FCC ID number. Both new 
and used Class A verified devices 
may be .sold only for use in com- 
mercial and industrial locations. 
Signals from computers are more 
likely to be masked by electrical 
noi.se from other equipment in such 
an environment. These areas are 
also likely to have fewer radios and 
TVs. Accordingly, equipment mar- 
keted only for use in these locations 
may meet the less rigorous Class A 
standard. Class B certified equip- 
ment may be marketed for use in 
residences as well as commercial 
and industrial locations. 

As you shop for a computer for use 
in your home, look for the FCC clas- 
sification in the specifications or ask 
your vendor to recommend only ma- 
chines that have been certified to the 
Class B limits. TV viewers and radio 
listeners in your home and in neigh- 
boring homes will be glad you did. 



